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POWER PROGRAMMING 

Memory Management and 
Mapped Files in Win32 



The segmented architecture of 
Intel 80x86 microprocessors 
has been the target of much 
scorn by aficionados of RISC 
or 680x0 CPUs, but this deri- 
sion is largely undeserved. The 
Intel protected-mode memory 
architecture, wherein a virtual 
address is composed of a han- 
dle (selector) and an offset, is an excellent 
substrate for a robust, multitasking envi- 
ronment, because it allows processes to 
be built out of memory "objects" that can 
be shared or segregated as distinct units 
vithout regard to their location in physi- 
cal memory. Moreover, the critics con- 
veniently ignore the segmentation in 
their own backyards: Some RISC proces- 
sors (such as the original IBM "America" 
RISC CPU) are burdened with segmen- 
tation under another name, while Macin- 
tosh applications are constructed from 
code resources that are not allowed to ex- 
ceed 32K. 

The real problem with segmentation 
on Intel processors was not so much that 
it existed, but that segments were limited 
to 64K. Because of this, the address arith- 
metic in large 80x86 programs with code 
or data spanning multiple segments was 
very complicated, and the performance 
of such large programs was correspond- 
ingly poor. 

When Intel designed its 80386 pro- 
cessor, segments were redefined in a way 
that allowed them to grow to 4GB, but 
this introduced a new problem: Segment- 
based virtual memory management was 
no longer feasible. Imagine a program's 
execution being suspended for several 
seconds or more while a segment of sev- 
eral megabytes was read in from the swap 
file, just to let the program access a single 
variable in that segment! Consequently. 
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Intel added another layer of virtual- 
memory management: the hardware pag- 
ing unit. 

When an Intel 80386 or 80486 is run- 
ning in protected mode with paging en- 
abled, there are two layers of virtual ad- 
dress translation. The selector and offset 
visible at the programming level are con- 
verted by the hardware segmentation 
unit — with the aid of descriptor tables 

A look at the evolution 



of memory management in 

Windows, especially the 
new mapped-file functions 
designed for the 32-bit flat, 
paged memory model. 



that are maintained by the operating sys- 
tem — into a 32-bit linear address. The lin- 
ear address, in turn, is remapped by the 
hardware paging unit with the aid of page 
tables and a page directory (again main- 
tained by the operating system) onto a 
32-bit physical address identifying a 4K 
page of RAM and an offset within that 
page, as shown in Figure 1. The result is 
a 64-terabyte virtual address space super- 
imposed on a 4GB physical address 
space. 

As you can see, interposing a paging 
layer eliminates nearly all of the prob- 
lems with segmented memory. Every ap- 
plication can be a "small" model, with a 
single, pure, shareable code segment and 
an instance data segment ranging in size 
from 1 byte to 4GB — while the operating 
system is free to allocate and swap physi- 



cal memory in nice, uniform, 4K chunks. 

One of the interesting aspects of the 
two-tiered virtual memory management 
architecture of the 80386 and 80486 is 
that it can readily mimic the flat 32-bit 
memory model of CPUs like the Motor- 
ola 68040 and the VAX. You can't ever 
disable segmentation on an Intel pro- 
cessor — segment registers must always 
be loaded with valid selectors — but you 
can choose to ignore it. This is accom- 
plished very simply by creating two de- 
scriptors, one for code and one for data, 
each mapping to the same giant memory 
segment at linear addresses to 4GB. 
Application code is mapped to addresses 
at the bottom of the segment, and operat- 
ing system code to addresses at the top 
of the segment (see Figure 2). The CPU's 
segment registers are loaded with the 
code or data selector as appropriate when 
the system starts up and is never touched 
again. All memory references, jumps, 
and calls are near; memory allocation, 
swapping, segregation of code from data, 
protection of operating system code, and 
the separation of one process's address 
space from another are all handled by 
manipulation of the page tables and page 
directory. Both OS/2 2.0 and NT/Win32 
use this flat-memory model when run- 
ning 32-bit applications. 

Why did the designers of OS/2 2.0 and 
NT/Win32 decide to forgo the significant 
benefits of the segmented paged-memory 
model and adopt the flat model with its 
much smaller virtual address space? The 
reasons are partly economic and partly 
technical. From an economic standpoint, 
there are many expensive, exotic, hard- 
ware-hungry applications currently avail- 
able only on workstations or supermini- 
computers. IBM and Microsoft hope to 
make porting of those applications to 
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32-bit base address from descriptor 
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Page directory 



Page table 



12-bit page offset 
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32-bit physical memory address 



lently to 32-bit near equivalents by the 
simple expedient of redefining FAR ar 
a no-op. All data types (such as LPSTR, 
that are built on top of the FAR keyword 
with TYPEDEFs thus collapse to near 
data types by default. Similarly, function 
prototypes that were previously declared 
with the FAR keyword or with FAR- 
based TYPEDEFs as being entered 
through far calls and exited through far 
returns devolve automatically to near 
functions. The arguments and results of 
the Windows memory management func- 
tions are affected by these redefinitions 
like everything else. 

For example, in Windows 3.x, the 
function GlobalLock() accepts a 16-bit 
handle and returns a selector and offset, 
while in Win32 the same function accepts 
a 32-bit offset and returns the same 32- 
bit offset. (In other words, in Win32 the 
function does absolutely nothing.) In 
both environments, GlobalLock() is pro- 
totyped as: 

LPVOID APIENTRY GlobalLock (HANDLE ) 



Figure 1: Memory addressing in 32-bit protected mode on the Intel 80386 and 80486 processors. The 
virtual address seen at the machine-code level, composed of a selector and offset, is translated by the 
hardware segmentation unit into a 32-bit linear address. The linear address is converted by the 
hardware paging unit into a 32-bit physical address. 



OS/2 2.0 and NT/Win32 easier— and con- 
sequently much more attractive — by hid- 
ing segmentation (incidentally opening 
up a new and far less price -sensitive mar- 
ket for systems software that until now 
has been the exclusive province of com- 
panies like Sun, Hewlett-Packard, and 
Silicon Graphics). 

The technical reason for this decision 
is that Microsoft and IBM are hedging 
their bets on the future of the micropro- 
cessor marketplace. Although the Intel 
80x86 processors still dominate the in- 
stalled base and their performance has 
improved dramatically with each succes- 
sive generation, there is no guarantee 
that the Intel 80x86 architecture won't 
simply ran out of steam. By abandoning 
segmentation, Microsoft and IBM have 
simplified the task of porting OS/2 or NT 
and their applications to other, non-Intel 
processors. 

THE WIN32 MEMORY MANAGEMENT API 
For an experienced Windows program- 
mer who has thought about the underly- 
ing memory models, converting a 16-bit 



Windows application for Win32/NT is a 
rather spooky business. The fundamental 
Windows memory management API — 
GlobalAllocQ, GlobalLock(), Global- 
ReAlloc(), GlobalUnlockO, Global- 
Free() — was originally designed for the 
paragraph-oriented, based-addressing 
architecture of the Intel 8086 real mode. 
It survived the transition to the Intel 
80286's 16-bit protected mode quite 
gracefully with the substitution of selec- 
tors for handles or paragraph addresses. 
But source code that was written for the 
16-bit Windows memory API (Winl6) 
compiles and runs fine on a MIPS R4000 
RISC CPU running Win32/NT even 
though the MIPS processor has no selec- 
tors at all! How can this be? This is infor- 
mation hiding with a vengeance! 

Most of the portability between the 
Winl6 and Win32 memory models and 
APIs is accomplished at the source code 
level with TYPEDEFs and #DEFINEs in 
the Windows header files. Far memory 
references, far pointers, and far jumps or 
calls are transformed cheerfully and si- 



The differences in the underlying mem- 
ory models are hidden from the applica 
tion within the definitions of the 
LPVOID, HANDLE, and APIENTRY 
data types (as shown in Figure 3). 

Another implication of this disappear- 
ance of far pointers in Win32 is that the 
Localxxx Windows API functions be- 
come mere aliases for their Globalxxx 
counterparts. The fact that this informa- 

The Flat-Memory Model 
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code and data 
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Application 
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Figure 2: The flat-memory model of OS/2 2.0 and 
NT/Win32 on Intel 80386 and 80486 processors. 
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pmtection is 
enough to 
make youfll. 




Frankly paying anything at all is 
pretty nauseating.- 

But that's nothing compared to 
the feeling you get in your stomach 
when a drive lull of data goes 
down the drain. 

So you pay. 

Then you pay again. For 
upgrades. Or quarterly "updates." 

But even that doesn't buy you 
much peace of mind. Because each 
new day brings an average of six 
new viruses into the world. 

Which means all anti-virus 
programs are inherently obsolete. 

Except one. 

Introducing Untouchable." The 
only software in the world that gives 
you 100% protection. 

Today. 

And tomorrow. 
Like other anti-virus software, 
Untouchable is equipped with a TSR 
monitor for patroling your system 
memory; plus a scanner/remover 
for examining the files on your disk. 
Between them, these first 
'o lines of defense can 

ify Untouchable Network 
<ivesyou centralized 
protection, 
you can install, 
monitor and control 
rithout having to 
your seat. 

ecognize and oblit- 
:rate over 1000 of the 
little buggers— 
enough to protect you from 95% of 
the potential carnage. 

If you find that statistic reassur- 
ing, then you probably like the odds 
in Russian Roulette. 

If you don't, you'll want to 



know that Untouchable is equipped 
with a unique third line of 
defense, which has been mathe- 
matically proven to be, well, 
untouchable. 

Instead of looking for viruses, 
this third line of defense looks for 
changes in your executable and 
system files. 

If the change is but a single byte, 
Untouchable will spot it and, using 
our patent-pending recovery tech- 
nique, reconstruct the file to its 
original state. 

The process is known as Generic 
Differential Detection, and certain 
other programs claim to perform 
it, too. 

But only Untouchable calculates 
file signatures using not one, but 
two proprietary algorithms mat 
can't be reverse-engineered. 

Only Untouchable guarantees 
100% safe recovery of infected 
files. (Unlike other programs 
that proudly generate corrupted 
files. Untouchable knows when 
the jig is up and doesn't attempt 
recovery.) 

Only Untouchable can provide 
centralized network virus protec- 
tion. In fact, Untouchable Network 
has enough virus alerts and report- 
ing mechanisms to settle the 
stomach of even the most nervous 
Netware® administrator. 

And only Untouchable is backed 
by our vaunted 24-hour toll-free 
technical support and a one-year 
money-back guarantee. 

If you're worried about viruses — 
and you should be — don't reach for 
the Maalox! 5 Reach for the phone. 
Dial 1-800-677-1848. 

You'll feel better right away. 
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Datatypes in Win16 and Win32 

Win16 Win32 


LPVOID 


void far* 
(32-bit pointer) 


void * 

(32-bit pointer) 


HANDLE 


unsigned int 
(16-bit value) 


unsigned int 
(32-bit value) 


APIENTRY 


far pascal 


_stdcall 


Figure 3: For the GlobalLockO function, the differences in underlying 
memory models is hidden within the definitions of these data types. 



tion hiding actually works and protects 
the existing Windows application source 
code base so effectively is one of the hap- 
piest events of microcomputing history. 
Certainly, when you consider that the 
basic Windows memory management 
API was created before the 80386 was 
even designed and RISC processors were 
still a laboratory curiosity, the API's 
adaptability to such an extreme variety 
of environments is little short of miracu- 
lous. The evolution of the traditional 
Windows memory API from 1985 to 1992 
is summarized in Figure 4. 

Of course, the Win32 API brings more 
to the table than just the traditional Win- 



dows memory manage- 
ment functions. In fact, if 
you are writing a 32-bit 
application from scratch 
for Win32 and portability 
to or from Win 16 is not 
an issue, you may find the 
prospect of using the tra- 
ditional functions some- 
what distasteful. You can 
turn instead to the new 
Win32 memory functions shown in Fig- 
ure 5, specifically designed for the 32-bit 
flat, paged memory model. 

The mapped-file functions, which are 
the ones we'll concentrate on in this in- 
stallment, are particularly interesting be- 
cause they can dramatically simplify 
applications. The concept behind 
mapped files is very simple. The data in 
a mapped file is associated with a range 
of addresses in the application's memory 
space. When the application touches a 
particular address within the mapped 
range for the first time, it causes a page 
fault, and the virtual memory manager 
will go directly to the file, retrieve the ap- 



propriate page-size chunk of data, and 
then place the data in memory at the cor- 
rect address. 

If the application modifies the con- 
tents of a page within the mapped range, 
the hardware will flag the page as "dirty," 
and the virtual memory manager will 
then automatically write that page back 
to the file when the physical page is 
needed for something else, the file is 
unmapped, or the program terminates. 

The mapped-file functions are elegant 
on several levels. The work of file buffer- 
ing is shifted away from the application 
onto the operating system's virtual mem- 
ory manager, which can take full advan- 
tage of its "magical" knowledge about 
the underlying paging hardware and the 
system's free memory resources. The ap- 
plication can freely access any location in 
the file at any time with a simple memory 
access, without worrying about allocat- 
ing, initializing, refilling, or flushing buff- 
ers. A mapped file's in-memory pages are 
demand-allocated out of the system's 
global pool, so if the overall load on the 
system is small, the amount of swapping 
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that is required for 
accesses to the 
mapped file will di- 
minish accordingly. 
A mapped file can 
be shared by two or 
more processes, in 
effect allowing the 
processes to com- 
municate through 
the file "view" and 
eliminating the re- 
dundant allocation 
of buffers. Best of 
all, no unnecessary 
file I/O is ever per- 
formed; the only file 
data that is trans- 
ferred from disk into 
memory is the data 
that the application ~—~ ~ ~ 
actually inspects or changes. 

USING MAPPED-FILE FUNCTIONS The 
first step in using the mapped-file func- 
tions is to open the file using the familiar 
Windows functions OpenFile(), Create- 
FileQ, or _lopen(), all of which return a 



Memory Management Under Windows 











Winnows d.l 


winjz/N i 


Windows API 




Windows 1.x 




(16-bit protected 


(32-bit protected 


Memory Function 


Parameters 


(real mode) 
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attributes, 
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results 


handle 




selector 


32-bit offset 


GlobalLock 


argument(s) 


handle 




selector 


32-bit offset 




results 


segmentoffset 




selectonoffset 


32-bit offset 


GlobalReAlloc 


argument(s) 


handle, 

number of bytes, 
attributes 




selector, 
number of bytes, 
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32-bit offset, 
number of bytes, 
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results 


handle 




selector 


32-bit offset 


GlobalUnlock 


argument(s) 


handle 




selector 


32-bit offset 




results 


flag 




flag 


flag 


GlobalFree 
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handle 
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32-bit offset 




results 
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selector 


32-bit offset 



Figure 4: The traditional Windows memory management API as it has evolved from the real-mode Windows of 1985 to the 32-bit 
protected-mode Win32 of today. 



file handle. The file handle is then sup- 
plied to the function CreateFileMap- 
ping(), along with several other parame- 
ters: the maximum number of bytes of the 
file to map, the access type (read-only or 
read-write), an optional security attri- 



bute, and an optional arbitrary name for 
the mapping. If CreateFileMapping() 
succeeds, it returns a handle to a file map- 
ping object. And by the way, as you begin 
to program for NT and to explore the 
parts of the Win32 API that are not pres- 
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• True 16-bit stereo audio 
record/playback to 44kHz 

• Built-in 100 watt stereo 
amplifier 

• High-quality speakers 

• MIDI interface 

• Photo CD ready 
(first session) 

• IBM standard joystick 
port 




• Advanced stereo 
synthesizer 

• Single cable and inter- 
face card for easy set up 

• Compatible with 
Sound Blaster™, 
Windows 3.1" and 
MPC sound 
standards 

• Optional bass 



Now go from CD pieces to CDPC". And avoid the hassle and high cost of buying separate 
components. Because the CDPC line of products are complete 16-bit multimedia CD systems 
bringing together all the excitement of CD-ROM sound and graphics — into one remarkably 
affordable, plug 'n play compact unit. For less than half the cost of the individual components. 

Plus, you'll get a bundle of top-selling software. Where in the World is Carmen Sandiego? — 
Deluxe Version, Compton's® Multimedia Encyclopedia and MacroMind Action! And for more 
demanding users, there's CDPC-XL with a double speed NEC CD-ROM drive for ultra-fast data 
access, and a SCSI bus connection for adding peripherals. 

So don't go to pieces. Simply get the ultimate. Visit U [ H I fl JTTl 
Mi7tm"e~PC a CDPC dealer near you and relax. PI L U I II lAA. J 

MediaVision, 3 1 85 Laurelview Court, Fremont, CA 94538. 510-770-8600, FAX: 510-770-9592. 
Media Vision CDPC and CDPC-XI. are trademarks of Media Vision, Inc. All other trademarks are the property of their respective companies © 1992, Media Vision, Inc. 
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Win32 Memory Management Functions 


Memory allocation 


VirtualAllocO, VirtualFreef), 




VirtualProtectO, Virtual QueryO 


Heap management 


HeapCreateO, HeapDestroyO, HeapAllocO, 




HeapFreef), HeapSizeO 


Mapped files 


CreateFileMappingO, OpenFileMappingO, 




MapViewOfFileO, MapViewOfFileExO, 




FlushViewOfFile(),UnmapViewOfFlle() 


figure 5: These new Win32 functions are specifically designed for the 32- 


bit flat, paged memory model. 



ent in Winl6, you're going to have objects 
coming out of your ears. Objects are 
everywhere in NT; they are the funda- 
mental unit of resource management. In 
fact, the NT microkernel's main mission 
is to create, destroy, and control access 
to objects. Objects as seen by an applica- 
tion are just handles representing hidden 
data structures (controlled by the operat- 
ing system) that encapsulate ownership 
and state information for processes, 
memory, files, semaphores, timers, and 
so on. 

In any event, once your program has 
a file-mapping object in hand, it calls the 
function MapViewOfFileQ to associate 
the mapping object with a range of mem- 



ory addresses. Map- 
ViewOfFileO nas a 
number of parame- 
ters, including the 
mapping object han- 
dle, an offset and size 
that allow a subset of 
the file to be mapped 
instead of the entire 
file, and an access 
type. Note that access 
rights are specified at 
three points during 
the mapping procedure: the opening of 
the file, the creation of the mapping ob- 
ject, and the mapping of the file view. All 
of the access rights must be consistent for 
the file mapping to work. 

Assuming that the MapViewOfFile() 
function succeeds, it returns a pointer 
and the contents of the file are immedi- 
ately "visible," using the pointer as an ad- 
dress base. (If the application needs to 
map the file at specific addresses, it can 
call MapViewOfFileExO rather than al- 
lowing the system to assign the 
addresses.) Suppose we want to create a 
mapped view of the file myfile.dat and 
zero out the byte at offset 2000h within 
the file. A skeleton for the required 



source code would look like this: 

HANDLE hFile, - 
HANDLE hMap ; 
LPSTR lpMap ; 



hFile = _lopen ( "myf i le . dat " . . . ) ; 
hMap = 

CreateFileMapping (hFile. . . ) ; 
lpMap - MapViewOf File (hMap . . . ) ; 
lpMap [0x2000] = 0; 

When the program is done accessing the 
file, it destroys the file mapping by calling 
UnmapViewOfFile(), releases the file- 
mapping object by calling CloseHan- 
dle(), and finally closes the file itself with 
Jclose or CloseHandle(). At any point 
in between, the program can force the in- 
memory and on-disk contents of the file 
to be brought into sync with the Flush- 
ViewOfFile() function. 

Two or more programs can arrange to 
use a mapped file for interprocess com- 
munication in several ways. A mapped- 
file object handle can be inherited by 
child processes. A handle can be 
duplicated and passed to other processes. 
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// HexView2 - Hex File Viewer for NT/WIN32 Using Mapped File Functions 

// Copyright (C) 1992 Ray Duncan 

// PC Magazine * Zi£f Davis Publications 



#de£ine ditn(x) (sizeof(x) 
tfdefine EXENAHESIZE 256 

#define BPL 16 

•include -stdlib.h' 

#include "windows . h" 

•include "string .h" 

•include "commdlg .h" 

•include "hexview.h" 

HANDLE hlnst; 
HWND hFrame ; 
HWND hChild; 

HFONT hFont; 

INT CharX, CharY; 

INT LPP; 

INT BPP; 

INT Thumblnc; 

INT WinWidth; 

INT hFile = -1; 

char szPileName [ EXENAMESIZE+1 ] 
LONG FileSize; 
LONG Filelndex; 

LONG ViewPtr; 
LONG TopAddr; 
LONG TopLine; 

HANDLE hMap; 
LPSTR lpMap; 



/ sizeof (x[0] > ) 



/ / returns no . of elements 

// max length of path+f ilename 

// bytes per line 



// module instance handle 

// handle for frame window 

// handle for child window 

// handle for nonprop. font 

// character dimensions 

// lines per page 

// bytes per page 

// bytes per thumb unit 

// width of frame client area 

// handle for current file 

// name of current file 

// length of current file 

// index from thumb tracking 

// addr, first line current page 

// address, top of last page 

// line num. top of last page 

// handle, file mapping object 

// base address, mapping object 



Remaining static variables and tables at start of program 
are unchanged from previous version of HEXVIEW. WinMainO 
and InitAppO routines are unchanged. 



// 

// Initlnstance instance initialization code for this application. 

// Gets information about system nonproportional font. Creates frame 

// window, gets initialization information (if any) from registration 

// database. Positions and sizes window, opens and positions previous 

// file if initialization info found. 
// 

BOOL Initlnstance (HANDLE hlnstance, INT nCmdShow) 



HDC hdc; 
TEXTMETRIC tm; 
RECT rect; 
char buff [80] ; 

hFrame = CreateWindow ( 
szFrameClass, 
szAppName, 

WS_OVERLAPPEDW1NDOW j WS_VSCROLL, 
CW_US EDEF AULT , CW_US EDE FAULT , 
CW_U S EDEF AU LT , CW_US EDE FAULT , 
NULL, 
NULL, 

hlnstance, 
NULL) ; 

if ( ! hFrame) return ( FALSE) ,- 



// handle for device context 

II font information 

// window position & size 

// scratch buffer 

// create frame window 

// window class name 

// text for title bar 

// window style 

// default position 

// default size 

// no parent window 

// use class default menu 

// window owner 

// unused pointer 

// error, can't create window 



hdc = GetDC(hFrame) ; // get device context 

hFont = GetStockObject (SYSTEM_FIXED_FONT) ; 

SelectObject (hdc, hFont) ; // realize nonproportional 

GetTextMetrics (hdc, S.tm) ; // font, get character size, 

CharX = tm. tmAveCharWidth; // and calculate window width 

CharY = tm.tmHeight + tm. tmExtemalLeading; 
WinWidth = (CharX * 75) * GetSystemMetrics (SM_CXVSCROLL) ; 
ReleaseDCfhFrame, hdc); // release device context 



GetWindowRect (hFrame, Srect) ; 



// get window position, size 



// read saved position/size profile for our frame window, if any 
rect.left = GetPrivateProfilelnt ( "Frame" , "xul", rect.left, szlni),- 
rect.top = GetPrivateProfilelnt ( "Frame" , *yul", rect.top, szlni); 



Figure 6: Extracts from the source code for the mapped-f ile version of HEXVIEW. The executable program and complete source code files are available for 
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See that sleek little black 
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using the world's first electronic 
slide projector. 
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fastest way to present, 
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HEXVIEW2.C 

2 of 2 



rect. right = GetPrivateProf ilelnt ( "Frame" , "xlr", rect. right, szlni) ; 
rect. bottom = GetPrivateProf ilelnt ( "Frame" , "ylr", rect. bottom, szlni); 

MoveWindow (hFrame, rect. left, rect. top, // force window position, size 
WinWidth, rect .bottom-rect . top, TRUE) ,- 

// get saved filename and file offset for display, if any 
GetPrivateProf ileString ( " File" , "filename" , " " , szFileName, 

EXENAMESIZE, szlni); 
GetPrivateProf ileString I "File" , " f ileptr" , " " , buff, sizeof (buff) , szlni) j 



if (szFileName(0] ) 



OpenDataFileO ; 
SetFilePosition (atol (buff) ) 



ShowWindow (hFrame, nCmdShow) ; 
UpdateWindow(hFrame) ; 
return(TRUE) ; 



// if filename and file offset 
// was saved from previous 
// execution, open the file 



ft make frame window visible 
// force WM_PAINT message 
// return success flag 



. Routines Termlnstance ( ) , FrameWndProc ( ) , ChildWndProc ( ) , 

. DoCommand ( ) , DoDestroy ( ) , DoClose ( ) , DoVScroll ( ) , DoPaint ( ) , 

. DoChildPaint ( ) , DoSizel) , DoHenuExit I ) , DoMenuAbout ( > , 

. AboutDlgProc ( ) , Repaint ( ) , SetFilePositiont ) , ConfigDi splay ( ) , 

. ThumbTrack ( ) , and UpdateFrameProf ile ( ) are unchanged from 

. previous version of HEXVIEW- Routines ReadDataFile ( ) and 

. GetBytel) are superfluous and are no longer present. 



// DoMenuOpen -- process File-Open command from menu bar. All 
// the hard work is done by the OpenFile common dialog. 



LONG DoMenuOpen I HWND hWnd, UINT wMsg, UINT wParam. LONG lParam) 



OPENFILENAME ofn; 



'\0' 



ofn.lStructSize = sizeof (OPENFILENAME) 
ofn.hwndOwner = hWnd; 
ofn.lpstrFilter = szFilterte] ; 
ofn.lpstrCustomPilter = NULL; 
ofn.nFilterlndex = 1; 
ofn. IpstrFile = szFileName; 
ofn.nMaxFile = EXENAMESIZE ; 
ofn.lpstrFileTitle = NULL; 
ofn.lpstrlnitialDir = NULL; 
ofn.lpstrTitle = NULL; 
ofn. Flags = OFN_ PATHMUSTEX 1ST 
ofn . IpstrDefExt = NULL; 

if (GetOpenFileName (&ofn) ) 
1 

OpenDataFileO ; 
Repaint ( ) ; 

) 

return (FALSE) ; 



// 

// SetwindowCaption — concatenate the specified filename with the 

// application name, then update the frame window's title bar. 

// If called with NULL pointer, removes any previous filename from 

// the title bar, leaving only the application name. 



// used by common dialogs 



// init filename buffer 



// length of structure 
// handle for owner window 
// address of filter list 
// custom filter buffer address 
// pick default filter 
// buffer for path+f ilename 
II length of buffer 
// buffer for filename only 
// initial directory for dialog 
// title for dialog box 
OFN_FI LEMUSTEXI ST ; 

// default extension 

// display open dialog 

// open file for viewing 
// force display of data 



VOID SetW 
( 



dowCaption (char * szName) 



char szTemp[EXENAWESIZE+l] ; 

iffszName == NULL) 

SetWindowText (hFrame, szAppName) ; 

else 
( 

strcpyfszTemp, szAppName) ; 
strcat(szTemp, ■ - ') ; 
strcat (szTemp, szName) ; 
SetWindowText (hFrame, szTemp) ; 

) 



// if null pointer, just 

// display application name 

/ / otherwise. . . 

// get application name 

/ / add separator 

// add filename 

// put result into title bar 



// 

// DisplayLine -- format and display a single line of hex /ASCI I dump 
II using the device context and relative window line number supplied 
// by the caller. The file data offset is calculated from the 
// relative window line and the offset corresponding to the line 
// currently at the top of the window. 
// 

VOID DisplayLine (HDC hdc, INT line) 
( 

INT i; 

chax buff [256] , c, *p; 
LONG x; 

if ((ViewPtr + (LONG) line'BPL) < FileSize) 
( 

// format file offset as fi-digit hex number 
p = buff + wsprintf (buff , "%081x *, ViewPtr 



(LONG) line'BPL); 



// format this 16-bytes as hex data 

for(i = 8; 1 < BPL; i++) 

{ 

x = ViewPtr + ( LONG) [line * BPL) + i; 

if(x < FileSize) 

p + = wsprintf(p, "%02X ", lpMapEx] & 0x0ff); 

else 

p += wsprintf (p, " " ) ; 



// format same 16-bytes as ASCII, 
for(i = 0; i < BPL; i++) 



x = ViewPtr + (LONG) (line - BPL) + i; 



for control characters 



if (x < FileSize) 



c = lpMaplx] ; 
if(c < 0x20) 



else c = ' 
*P++ = c; 



// append a null byte, then paint the formatted data 
*p = '\0' ; 

TextOuUhdc, 0, line*CharY, buff, strlen[buff ) ) ,- 



// OpenDataFile -- open specified file for viewing, save handle. The 

// filename was previously placed i_n szFileName by OpenFile common dialog. 

VOID OpenDataFile (VOID) 



char temp [2 56] ; 

if(hFile != -1) 
I 

UnmapViewOfFile(lpMap) ; 
CloseHandle(hMap) j 
_lclose (hFile) ; 

> 



// scratch formatting buffer 

// if previous file, 
// release mapping object 

// and view, then close 
// the file 



// remove any previous filename from title bar 
SetWindowCapt ion (NULL) ; 



hFile = _lopen(szFileName, OF_READ) ,- 



if (hFile == -1) 



// try and open the new file 
// error, no such file 



wsprintf (temp, -Can't open file: %s", szFileName); 
MessageBox (hFrame, temp, szAppName, MB_ICONSTOP | MB_OK) ; 
return; 



FileSize = _llseek (hFile, t, 2); 
0) 



if (FileSize 
( 

MessageBox (hFrame, "File is empty!", szAppName, 

MB_ICONSTOP j MB_OK) ; 
_lclose (hFile) ; 
hFile = -1; 
return; 

) 

// create file mapping object with no maximum size 
hMap = CreateFileMapping ( (HANDLE) hFile, 

( LPSECURITY_ATTRIBUTES ) NULL, PAGE_READONLY , 0, 



// get size of file 
// error, nothing to display 



if (hMap == 0) 



(LPSTR) NULL) ; 
// error, no object available 



MessageBox (hFrame, "Can't create file mapping object!", 
szAppName, MB_ICONSTOP \ MB_OK) ,- 

_lclose(hFile) ; 
hFile = -1; 



U mapping object created, now map view of file onto object 
IpMap = (LPSTR) MapViewOf File (hMap, FILE_MAP_READ , 0, 0, 0) ; 



ifUpMap == 0) 



// error, no view created 



MessageBox (hFrame, "Can't map view of file! 

szAppName, MB_ICONSTOP j MB_OK) ; 
CloseHandle(hMap) ; 
_lclose (hFile) ; 
hFile = -1; 
return; 



ViewPtr = 0; 
Conf igDisplay ( ) ; 
SetWindowCaption(szFileName) ; 



// reset window address pointer 

// set up scroll bar 

// put filename in title bar 
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Which is really 
the fostest database? 



NSTL Performance Scores 
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dBASE IV Paradox 


FoxPro/LAN 



Microsoft FoxPro 2.0 is the fastest 
PCDBMS...fasterthan dBASE IV' 1.5, 
and foster than Paradox 4.0} 



See for yourself. 




i 



I KKPR0 : W 



If you use dBASE ; 
Paradox; Clipper" or 
any other PC database, 
you should know that 
FoxPro 2.0 has been 
consistently rated 
the fastest database 
— as recently as an 



Upgrade to Microsoft FoxPro 2. 
for$199andgetversion2.5FREE 

independent September 1992 NSTL lab report! 

And if you use any other database, there's 
something else you should know about — a way to 
really see, for yourself, which is the fastest data- 
base around. With this special, limited-time offer 
from Microsoft, you can get Microsoft* FoxPro 
database version 2.0 (single user version) for just 
$199,' with a free- upgrade to version 2.5 for 



MS-DOS* or for Windows 1 operating systems as 
soon as it's released. 

Just call before December 31, 1992 and get 
a great deal on the fastest PC DBMS available. 
Plus a great deal of support. With Microsoft's full 
commitment, Microsoft FoxPro is sure to stay at 
the head of the database pack. 

For more information about Mcrosoft FoxPro's 
performance, for the name of a dealer near you, or 
to order direct from Microsoft, call now. 

Call (800) 228-7007, Ext. AM9 

Microsoft 

Making it easier 



© 1992 Microsoft Corporation. All rights reserved. Printed in the USA. 

* Plus $10.00 freight and applicable sales tax. Reseller prices may vary. "Free, you don't even pay freight. tdBASE IV and Paradox Benchmarks from an independent NSTL Report and Softtvare Digest 
rating report, vol. 9. No. 2. You must currently be a licensed user of a database product to qualify for this upgrade offer, lb qualify for this offer at your reseller you must bring proof of purchase with 
you: 1) the original disk from your program. 2) title page of the manual, or 3) a copy of the sales receipt. If you get your upgrade directly from Microsoft, you will be automatically registered. You must 
register your copy of Microsoft FoxPro 2.0 to qualify for a free upgrade to version 2.5. You will then be notified when your free upgrade is available. Offer expires December 3t 1992. Offer good only in the 
50 United States. Limit one copy of Microsoft FoxPro version 2.0 and one free upgrade to version 2.5 per product license. Please allow 2-4 weeks for delivery upon receipt of this order by Microsoft. In the 
50 United States, call (800) 228-7007, Ext. AM9. For information only: In Canada, call (800) 563-9048; outside the 50 United Sates and Canada, call (206) 936-8661. Microsoft, MS-DOS and FoxPro are 
registered trademarks and Windows is a trademark of Microsoft Corporation. dBASE. dBASE IV, and Paradox are registered trademarks of Borland International, Inc. Clipper is a trademark of 
Nantucket Corporation. Software Digest is a registered trademark of NSTL Inc. Datapro Company. 
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Step Up to 
Word for Windows. 




-030-0 



Step up to professional-quality documents with 
PC Magazine Guide to Word 2.0 for Windows. Best- 
selling author Ed Jones is a recognized master of the 
step-by-step writing style, which means quick learning 
with minimum effort. Crystal-clear explanations and 
dozens of generously illustrated examples will guide 
you from everyday typing and formatting right up 
through form letters, envelopes, tables, and even desk- 
top publishing — all the supercharged features that are 
making Word 2.0 for Windows the emerging choice 
among Windows word processors. With each easy-to- 
follow chapter, Jones brings you one giant step closer to 
Word for Windows mastery. 



Available at fine bookstores, or call 

1-800-688-0448 

ext. 1330 



PRESS 



© 1992 Ziff-Davis Press 



PROGRAMMING 

Power Programming 

If a name was assigned to the mapping 
object during the call to CreateFileMap- 
ping() and the security attributes allow 
it, other processes can open the mapping 
object by name with the function Open- 
FileMappingQ. As a special case, there 
is also a way to use the mapped-file func- 
tions for interprocess communication 
without an associated file, roughly equiv- 
alent to the named shared-memory seg- 
ments of OS/2. 

In order to provide a practical exam- 
ple of programming the mapped-file 
API, I've modified last issue's HEX- 
VIEW utility to produce a new version 
that eliminates explicit file buffering in 
favor of file mapping. We don't have 
space to print the complete listing here, 
but extracts of the source code relevant 
to the use of mapped files can be seen 
in Figure 6, and the complete source code 
and executable program can be down- 
loaded from PC MagNet, archived as 
HEXVI2.ZIP. Ironically, the most im- 
portant parts of the program conversion 
are the parts you won't find either here 
or on PC MagNet: The code to allocate 
and release a file I/O buffer and the rou- 
tines ReadDataFile() and GetByte() all 
go away, as they are not needed. 

FURTHER READING These references 
can help you learn more about managing 
memory in a 32-bit environment: 

• Win32 Programmer's Reference: Over- 
views. Chapter 2, "Memory Manage- 
ment," and Chapter 7, "File Mapping." 
Microsoft Press, Redmond, Washington, 
1992. 

• "An Introduction to Windows NT 
Memory Management Fundamentals," 
by Paul Yao. Microsoft Systems Journal, 
July/August 1992, volume 7, number 4, 
page 41. 

• Microsoft's 80386/80486 Programming 
Guide, 2nd Edition, by Ross Nelson. Mi- 
crosoft Press, Redmond, Washington, 
1991. ISBN: 1-55615-343-0. 

• Programming the 80386, by John Craw- 
ford and Patrick Gelsinger. Sybex Inc., 
Alameda, California, 1987. ISBN: 0- 
89588-381-3. 

THE IN-B0X Please send your ques- 
tions, comments, and suggestions to me 
at any of these electronic mail addresses: 
PC MagNet: 72241,52 
MCI Mail: rduncan 
BIX: rduncan 

Internet: duncan@csmc.edu □ 
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